Over many years there has been the development of many multiple listing services (MLSs) that provide property listing aggregations for participating real estate brokers, real estate agents, and other participants in the real estate transaction chain. Historically, these entities have been very regional in nature, so that the details of property listing information although somewhat common have diverged widely in their specification. The basic fields, such as lot size, list price, size of building, number of bedrooms, etc., are present in all MLSs but even the representation and format of these common fields varies. Beyond the basic nature of the data collected by MLSs, their formatting varies widely.
In this equivalent period of time, real estate brokers and other entities that rely on receiving information from the MLSs have become less local and more regional. The business models have changed due in part to the wave of mergers and acquisitions that form much larger entities from what were historically localized real estate offices. These real estate brokers today are often faced with many different MLSs and their corresponding data formats, which lead to inefficiencies in the processing of property listing information. This has caused a certain degree of frustration in the industry as to MLSs that occupy neighboring regions because they may have quite different data structures to represent the property listing information.
FIG. 1 shows a prior art system 10 and method for searching among a plurality of MLS databases (MLS Databases A, B and C). This solution may be adequate for searching a plurality of MLSs that contain predominately the same information. But it is wholly inadequate for the more likely scenario where largely different MLS listing databases need to be searched. For example, it has been shown that as few as even the coordination of three separate MLS databases significantly reduces the numbers of common fields to unacceptable levels. This means that search making these databases in any practical sense to retrieve property listing information is not feasible. This is primarily due to the very small overlap that is likely in field definitions between the MLSs. As shown in FIG. 1, there may be only a relatively small subgroup of fields (bedrooms, bathrooms, square feet, stories, pool and fireplace) that are shared between MLS Database A, B and C. The information related to non-common fields among the databases are not utilized and cannot be universally searched.
One attempt to address this issue has been the development of an XML standard for the transfer or exchange of property listing information. This XML standard, which may be referred to as Real Estate Transaction Specification (RETS), has been developed by industry members over the last decade. Although the RETS standard has gone a long way to allowing electronic interchange of listing information at the protocol level as well as defining common basic fields (the Standard Names of the specification), it has not been complete enough to fully address issues concerning the interchange of data. For example, the standard does not cover the commercial classes of real properties at all. Some of the reasons for this lack of functionality has been organizational as well as the challenges and complexities in trying to find or adopt a common standard that takes into account all the various local fields necessary to support various MLSs. RETS provides a specification from which a mechanism can be implemented so that information from an originating MLS may be processed in an automatic fashion, but the standard remains inadequate in fully addressing the exchange of the various kinds of information among different MLSs.
FIG. 2 also shows a known system 20 that attempts to improve the situation as described above by performing a first level combined field search that is followed by a detailed search in a child (native) database. A more detailed description of the system is described in U.S. Pat. No. 6,519,618 (Snyder) which is incorporated by reference herein in its entirety. A plurality of databases may be accessed initially and the various schemas employed can be resolved in order to establish common fields among the databases. Moreover, distinct fields from each database are established too. When a user interface is displayed and presented, a user selects both a root database and a child database. The results from the particular query are returned to the user that includes information derived from the root database and the child database. This system still remains deficient from a search perspective as the logic necessary to retrieve listing information relies on the search mechanism understanding the different semantics as they apply across a multiplicity of MLSs. This is due to the fact that the field names, data types, and semantics may very from MLS to MLS even though the initial search was against common fields.
Accordingly, there is a need for a solution that provides a comprehensive source of information conforming to a common schema across multiple MLSs.